1. Technical Field
This invention generally relates to computer systems, and more specifically relates to database apparatus and methods.
2. Background Art
Database systems have been developed that allow a computer to store a large amount of information in a way that allows a user to search for and retrieve specific information in the database. For example, an insurance company may have a database that includes all of its policy holders and their current account information, including payment history, premium amount, policy number, policy type, exclusions to coverage, etc. A database system allows the insurance company to retrieve the account information for a single policy holder among the thousands and perhaps millions of policy holders in its database.
Retrieval of information from a database is typically done using queries. A query usually specifies conditions that apply to one or more columns of the database, and may specify relatively complex logical operations on multiple columns. The database is searched for records that satisfy the query, and those records are returned as the query result. Structured Query Language (SQL) is one specific query language that may be used to query a database.
U.S. Pat. No. 6,915,291 entitled “Object-Oriented Query Execution Data Structure”, issued on Jul. 5, 2005, discloses an object oriented data structure that includes a plurality of node objects arranged in a tree relationship to define a query. The nodes include both data and code that allow the query to be executed. The result is a query architecture that is significantly extendible and adaptable.
One potential problem with the query execution data structure in U.S. Pat. No. 6,915,291 is the complexity of the data structure for complicated queries. The resulting data structure can have hundreds or even thousands of nodes. A query of this complexity becomes very difficult to debug. Debugging queries is important for two primary reasons. The first is to check the logic of the query itself, to make sure the query is properly defined. The second is to check the run-time performance of the query.
Statement level debuggers are known in the art, and have been used to debug queries. The problem with a statement level debugger is that a breakpoint is typically set when a particular object is executed. Note, however, that a given object type may appear in a query execution data structure at a number of different locations, each executing the same implementation methods, but potentially only one of these objects is actually contributing to the problem being debugged. For example, if a query execution data structure has ten instances of an object, and a breakpoint is set to break execution when that object type is executed, the debugger will break execution each time any of the ten instances of the object are executed, even though most of the instances may not contribute to the problem. The result is a debugger that breaks an excessive number of times.
Current debuggers do not have the capability of executing a query execution object to the point of failure, and halting execution at the proper place and time in the code, even using elaborate debugger macros. As a result, it is very difficult, if not impossible, to debug a complex query execution data structure that includes many query execution objects using known statement level debuggers. Without a way to debug query execution data structures, the prior art will continue to suffer from inefficient ways of debugging queries.